Improve project view status handling - #10

src/templates.ts (1)

32-35: Consider using CADDY_DOCKER_POLLING_INTERVAL env var for consistency.

The existing CADDY_INGRESS_NETWORKS is already configured via the environment: block. The caddy-docker-proxy docs show CADDY_DOCKER_POLLING_INTERVAL=<duration> as the equivalent env var for the polling interval. Using the env var keeps all runtime configuration in one place and avoids the need to override command: (which replaces the image's default CMD).

♻️ Alternative using env var (no command block needed)

-    "    command:",
-    "      - docker-proxy",
-    "      - --polling-interval",
-    "      - 5s",
     "    ports:",
...
     "    environment:",
     `      CADDY_INGRESS_NETWORKS: ${DEFAULT_INGRESS_NETWORK}`,
+    "      CADDY_DOCKER_POLLING_INTERVAL: 5s",

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/templates.ts` around lines 32 - 35, Replace the explicit command override
for docker-proxy with the equivalent environment variable: remove the "command:"
array entries (the docker-proxy/--polling-interval/5s lines) and instead add an
environment variable CADDY_DOCKER_POLLING_INTERVAL set to the desired duration
alongside the existing CADDY_INGRESS_NETWORKS in the environment block so
runtime config remains consistent and the image default CMD is preserved.

tests/coredns-config.test.ts (1)

27-39: Command block assertions are tied to the static-IP test case, but the block is unconditional.

The command: / docker-proxy block in renderGlobalCaddyCompose is emitted regardless of useStaticCaddyIp / useStaticCoreDnsIp. Bundling these assertions into the static-IP test provides no coverage for the default render path. Consider adding a dedicated test or a simple standalone assertion:

♻️ Suggested additional test for the default render path

test("renderGlobalCaddyCompose always includes docker-proxy command", () => {
  const text = renderGlobalCaddyCompose();
  expect(text).toContain("command:");
  expect(text).toContain("- docker-proxy");
  expect(text).toContain("- --polling-interval");
  expect(text).toContain("- 5s");
});

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/coredns-config.test.ts` around lines 27 - 39, The test currently
couples assertions for the unconditional "command:/docker-proxy" block with the
static-IP case, leaving the default render path untested; update tests to either
extract the docker-proxy assertions into a separate test that calls
renderGlobalCaddyCompose() with no args (e.g., a new test
"renderGlobalCaddyCompose always includes docker-proxy command") or move those
assertions out of the static-IP test so the static-IP test only asserts
IP/network lines (references: renderGlobalCaddyCompose, DEFAULT_CADDY_IP,
DEFAULT_COREDNS_IP). Ensure the new/adjusted test verifies "command:", "-
docker-proxy", "- --polling-interval", and "- 5s" are present.

apps/macos/Packages/Features/DashboardFeature/Sources/DashboardFeature/GlobalStatusStrip.swift (3)

858-883: Corner radius reset task uses a hardcoded delay that differs from the named constant pattern.

collapseSelectorPanel uses 140_000_000 nanoseconds directly (line 873) while other delays are defined as named computed properties (e.g., selectorCloseDelayNanoseconds). For consistency, consider extracting this into a named property.

♻️ Proposed fix

+  private var selectorCornerResetDelayNanoseconds: UInt64 {
+    140_000_000
+  }
+
   private func collapseSelectorPanel() {
     ...
     selectorCornerResetTask = Task {
-      try? await Task.sleep(nanoseconds: 140_000_000)
+      try? await Task.sleep(nanoseconds: selectorCornerResetDelayNanoseconds)
       ...
     }
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/macos/Packages/Features/DashboardFeature/Sources/DashboardFeature/GlobalStatusStrip.swift`
around lines 858 - 883, The collapseSelectorPanel function contains a hardcoded
sleep delay (140_000_000 ns) for selectorCornerResetTask; replace this literal
with a named computed property (e.g., selectorCornerResetDelayNanoseconds or
reuse an existing selectorCloseDelayNanoseconds if appropriate) and use that
property in the Task.sleep call, update any related comments/tests to reference
the new constant, and ensure the property is declared near other timing
properties so the timing pattern remains consistent across
selectorExpand/collapse logic.

---

571-583: RelativeDateTimeFormatter is allocated on every computed property access.

This computed property creates a new RelativeDateTimeFormatter each time the view body evaluates. Consider making it a static let or caching it to avoid repeated allocation.

♻️ Proposed fix: hoist formatter to static

+  private static let relativeFormatter: RelativeDateTimeFormatter = {
+    let f = RelativeDateTimeFormatter()
+    f.unitsStyle = .abbreviated
+    return f
+  }()
+
   private var lastUpdatedText: String? {
     guard let date = model.lastUpdated else { return nil }
-    let formatter = RelativeDateTimeFormatter()
-    formatter.unitsStyle = .abbreviated
     let now = Date()
     if date > now {
       return "Updated just now"
     }
     let delta = now.timeIntervalSince(date)
     if delta < 5 {
       return "Updated just now"
     }
-    return "Updated \(formatter.localizedString(for: date, relativeTo: now))"
+    return "Updated \(Self.relativeFormatter.localizedString(for: date, relativeTo: now))"
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/macos/Packages/Features/DashboardFeature/Sources/DashboardFeature/GlobalStatusStrip.swift`
around lines 571 - 583, The computed property lastUpdatedText repeatedly
allocates a RelativeDateTimeFormatter on every access; change to use a shared,
lazily-initialized formatter (e.g. a static let or cached instance) so the
formatter is reused. Locate lastUpdatedText and replace the local "let formatter
= RelativeDateTimeFormatter()" with a reference to the shared formatter (ensure
its unitsStyle = .abbreviated is set when creating the static), keep the same
logic using model.lastUpdated, Date(), and timeIntervalSince(date), and ensure
thread-safety by using a static let or a DispatchOnce-style lazy initializer.

---

15-25: Consider grouping related hover/expansion state into a dedicated struct or observable.

Ten @State properties for a single hover-expand interaction add cognitive load. While functional, extracting them into a small SelectorExpansionState struct (or a lightweight observable) would improve readability and make it easier to reason about the state machine.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/macos/Packages/Features/DashboardFeature/Sources/DashboardFeature/GlobalStatusStrip.swift`
around lines 15 - 25, Group the closely related hover/expand state
(isSelectorHeaderHovered, isSelectorPanelHovered, isSelectorExpanded,
isSelectorListVisible, selectorUsesExpandedCorners, hoveredSelectorProjectId,
selectorExpandTask, selectorCollapseTask, selectorListRevealTask,
selectorCornerResetTask, stripContentWidth) into a single small model (e.g.,
struct SelectorExpansionState or class SelectorExpansionModel: ObservableObject)
and replace the individual `@State` properties in GlobalStatusStrip with one
`@StateObject` or `@ObservedObject` instance; update all references and bindings to
use the new model’s properties (and expose any Task handlers as methods on the
model if needed), ensuring SwiftUI updates work the same way and that
initialization and lifecycle (creation, cancelation of tasks) are handled inside
the new model.

apps/macos/Packages/Features/DashboardFeature/Sources/DashboardFeature/HomeDashboardView.swift (2)

449-456: DashboardSessionEntry synthesizes Hashable over full model objects.

The struct holds ProjectSessionSummary and optional ProjectSummary, so synthesized Hashable will hash all their fields. This is fine for typical project counts but worth noting — if these models grow large, consider implementing Hashable manually using just the id.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/macos/Packages/Features/DashboardFeature/Sources/DashboardFeature/HomeDashboardView.swift`
around lines 449 - 456, DashboardSessionEntry currently derives Hashable for the
full session and project models which will hash all fields; change this to a
manual, ID-based hash by removing the synthesized Hashable conformance and
implementing Hashable (and Equatable) where hash(into:) only feeds session.id
and project?.id (or use the existing id property) and equality compares the same
IDs; update the type declaration for DashboardSessionEntry and add the
hash(into:) and == implementations referencing session.id and project?.id to
avoid hashing large model contents.

---

309-323: attachCommand and shellQuote are duplicated from ProjectDetailView.

Both attachCommand(for:) (lines 309–316) and shellQuote(_:) (lines 318–323) are identical to their counterparts in ProjectDetailView.swift (lines 1898–1905 and 1932–1937). Additionally, SettingsOverlayView.swift has a shellQuote with a different escaping strategy ('\'' vs '"'"'), which could cause subtle inconsistencies if one is used over the other.

Consider extracting these into a shared utility (e.g., on TerminalIntegration or a small helper extension) to avoid divergence.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/macos/Packages/Features/DashboardFeature/Sources/DashboardFeature/HomeDashboardView.swift`
around lines 309 - 323, Duplicate implementations of attachCommand(for:) and
shellQuote(_:) exist across HomeDashboardView, ProjectDetailView, and a variant
in SettingsOverlayView; extract a single shared implementation (for example as
static helpers on TerminalIntegration or a small ShellQuote helper) and replace
the duplicated methods with calls to that shared API. Move the tmux/zellij logic
from attachCommand(for:) and the robust escaping used in shellQuote(_:) into the
new helper, update HomeDashboardView.attachCommand(for:) and
ProjectDetailView.attachCommand(for:) to call the shared function, and
consolidate SettingsOverlayView to use the same escaping strategy to avoid
divergence.